home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 8
/
QRZ Ham Radio Callsign Database - Volume 8.iso
/
pc
/
files
/
p_misc
/
netconf.arc
/
MAILER.TXT
< prev
next >
Wrap
Text File
|
1988-12-10
|
16KB
|
327 lines
The Design of a Mail System for the KA9Q Internet
Protocol Package
Bdale Garbee, N3EUA
Gerard van der Grinten, PA0/GRI
_A_B_S_T_R_A_C_T
The current implementation of the mail manipula-
tion system that has been built by N3EUA and PA0/GRI
for the KA9Q Internet Protocol Package is described
briefly. A proposal for the next generation of net-
work mail handling for the KA9Q Internet environment
is described. An important change in the way we can
and should think about electronic mail in the amateur
packet radio world is discussed.
_B_a_c_k_g_r_o_u_n_d:
Since the conception of ``Amateur Packet Radio'', quite a bit of
evolution has occurred. Many lessons have been learned the hard
way, and many are yet to be learned. However, one point which
has become increasingly obvious to those of us involved in the
development of packet radio software, is that a much more con-
sistent and powerful way of dealing with electronic mail mes-
sages is
In the beginning, there was raw data transfer from point A to
point B without any protocol, and it was good. Then came a pro-
tocol called AX.25, which allowed for error-free point-to-point
virtual circuit links, and it was better. Most recently has
come an implementation of the DARPA TCP/IP protocol family, and
it is the best so far. The fact that this protocol family
includes a defacto real-world mail-handling protocol, SMTP, has
caused some interesting changes in the way we think about mail
in packet radio.
The current state-of-the-practice in amateur digital mail han-
dling is for one user, or ham, to ``log into'' a local PBBS sys-
tem, by establishing a virtual circuit to the PBBS's user inter-
face. He can then enter, read, or delete a given message, and
then ``log off''. Whenever users are not connected to the PBBS,
it is available to attempt ``forwarding'' of the mail, a process
in which ``packets'' consisting of entire messages are routed
from one PBBS to another. Once the message has arrived at the
destination system, the end user or ham can read the message
December 6, 1988
using the same ``connect to the PBBS'' sequence that the sender
used.
There are some fundamental design problems with this process.
It works, and has solved the first part our mail-handling needs.
But it requires that both the sending and receiving participants
spend a non-trivial amount of their time interacting with a
remote user-interface, which implicitly includes waiting for
channel throughput on the AX.25 circuit. In addition, there are
very few services available to the user, such as message archiv-
ing or printing, message forwarding, editing of messages, etc.
It is also the case that some mechanism (usually beacons) must
be provided to allow the receiving mail user to know that there
is a message waiting for him on his local PBBS.
It is interesting to note that these limitations are well-known
and understood in the packet community. An interesting trend
has been the creation of programs to allow machines such as the
Tandy 100 and C64 to serve as ``mini-PBBS'' systems, or ``per-
sonal mailboxes''. Moving as much of the mail user interface
from a remote system to the user's local computer as possible
provides several benefits. The user need no longer suffer the
delays associated with packet flow on the channel while
interacting with the mail system, and it becomes possible to
provide features such as message filing, printing, and more
extensive reply and forward capabilities. While this may not
have been possible in the early days of packet radio due to the
use of dumb terminals as packet stations, almost all packet
radio stations today include a computer as the end terminal.
While a transfer of the mail user interface from a PBBS to the
user's local machine is in theory possible with any underlying
network protocol family, the recent development by KA9Q and oth-
ers of a complete implementation of the DARPA TCP/IP protocol
family, including the defacto-standard mail transfer protocol
SMTP, has hastened the need for such a transfer. Implementing a
rational mail user interface and underlying servers for the KA9Q
Internet Package has been a most challenging task, with the
resulting system's design principles and implementation trade-
offs occupying the remainder of this paper.
_T_h_e _C_u_r_r_e_n_t _I_m_p_l_e_m_e_n_t_a_t_i_o_n:
The current mail system in the KA9Q Internet package consists of
an SMTP server and SMTP client that are integrated into the
NET.EXE package, and a separate mail user-interface. The mail
user interface, while currently sporting a very terse user
interface, provides facilities for creation and reading of mes-
sages, and some crude message filing capabilities.
When a user wishes to send a mail message, he runs the mail user
interface program _B_M, and enters the destination address, sub-
ject, and text of his message. The message is queued in a
directory on his machine for later transmission. At regular
December 6, 1988
intervals, the SMTP client in NET.EXE scans the queue directory
and attempts to process waiting outbound mail messages. Each
message is delivered by the client directly to the server at the
destination station.
When an incoming message arrives at the local SMTP server, it is
appended to a mailbox file, the name of which is based on the
username given in the destination address. Multiple real or
pseudo-users (for mailing lists) are therefore supported on a
given machine. At his leisure, the user can run the _B_M user
interface to read and manipulate the messages in his mailbox
file(s), and/or can manipulate them directly as disk text files.
The biggest change from existing PBBS mail handling is that the
user never has to wait for a packet to be transferred on the
channel. All on-air activity is handled automatically ``in the
background''.
_E_n_v_i_r_o_n_m_e_n_t:
As may be obvious, the design concepts and implementation ideas
presented here are applicable regardless of the particular com-
puter facilities in use, and/or the specific low-level transport
protocol and mechanism available. However, for the sake of com-
parison and reference, we will describe briefly the hardware and
software environment under which our mailer implementation has
been developed.
The KA9Q Internet Package has been developed on the IBM PC, and
close compatibles. It uses the Intel Small Memory Model, which
allows 64k of code space and 64k of data space on the 8088 pro-
cessor. In an effort to avoid the necessity of going to a large
memory model with the attendant segment maintenance overhead on
the 8088, and as an aid to generality and portability, functions
such as the mail user interface are being developed as separate
applications, designed to run concurrently with the KA9Q Inter-
net Package using a PC multitasking package such as Doubledos.
In the future, the ideas and algorithms presented here will most
likely be implemented under Minix/Unix as well.
Hardware requirements are essentially the same as for the KA9Q
package itself, except that mail handling can frequently consume
considerably more disk space that is required for the protocol
package to run, meaning that a large forwarding site will need a
hard disk. A simple single or dual user PC should be able to
get by on one 360k floppy drive.
All of the mailer software, as with the rest of the KA9Q pack-
age, has been written in C using the Aztec MS-Dos compiler. It
is therefore extremely portable, with the exception of a small
module of PC-specific file-system oriented functions, which
should be easily translatable to other operating environments.
December 6, 1988
_T_o_p-_L_e_v_e_l _D_e_s_i_g_n - _O_u_r _G_o_a_l_s:
The next step in the development of our mail system is parti-
tioning of the mail handling tasks. We choose to separate our
operations into four distinct categories: user interface, rout-
ing, reception, and delivery.
The user interface level is fairly obvious. This is the hunk of
code that the user actually sees, and which allows him to enter,
read, print, file, delete, forward, etc., all of the messages he
must deal with. There can and should be an ability to support
multiple user interfaces, to deal with varied and changing user
needs, hardware availability, etc.
In the middle, a ``routing agent'' receives requests from user
interfaces, and determines the appropriate target address and
delivery agent for each message. It is the only place in which
knowledge about the mapping between mail addresses and mail
delivery techniques should exist.
At the other end of the scale are the (potentially multiple)
mail delivery agents. These are the functional blocks designed
to take a message in a reasonable format (for them), and actu-
ally do the work of delivering it. In the SMTP world, this might
entail opening a TCP connection to the destination host, and
engaging in the SMTP protocol to deliver the message. In the
UUCP world, this might include looking up and dialing an
appropriate telephone number, performing the login dialog, and
then engaging in the required uucp protocols (similar to the way
uucico works under Unix). In the Fido world, this might simply
be a matter of reformating the message file into a Fido- compa-
tible message, and moving it to an appropriate directory on a
PC's hard disk.
The final class of entity is the mail reception agent. Each
server receives inbound messages from one of potentially many
mail services and puts them in the routing agent's queue, in the
same manner that a user interface queues a new message for pro-
cessing.
The flow of information therefore includes an influx of messages
to be handled, both locally created by the user and his inter-
face, and remotely created and received by a server. All pend-
ing messages pass into a queue and are processed by the router.
The router places each message, potentially with some additional
delivery information, into the queue associated with a particu-
lar mail delivery agent. Each delivery agent watches its queue
for messages to process, and attempts to deliver them.
_T_h_e _C_o_r_e _o_f _t_h_e _I_m_p_l_e_m_e_n_t_a_t_i_o_n:
Some simple observation of the mail management system that we
have thus far described should reveal the fact that a consider-
able amount of work will be done enqueueing and dequeueing
December 6, 1988
messages in a set of queues, one for the routing agent and one
for each delivery agent. To allow for a consistent means of
handling queue'ed messages, a combination of file system usage
and custom databasing routines has been laid out.
In the most general case, a queue entry will consist of two
files, one for the text of the message (most likely in RFC822
format), and one for the ``work'' information required by a par-
ticular delivery agent, or the router. A very reasonable idea
is to force each of these files to have a completely unique
name. Thus, the primary task of the database is to manage file
naming, and connection of a given text file with it's associated
work files. Exact details of the database are the topic of
current design effort as of this writing.
The routing agent is an extremely important part of this design.
It must ``read'' each message and make some determination about
which delivery agent should be used, and what address the
delivery agent should try to deliver to. In some situations,
such as forwarding uucp mail, which is frequently source-routed,
there is information external to the message body that will
allow the router to ``cheat''. In the majority of cases, how-
ever, the router will have to deduce the appropriate agent and
address by reading the To: address field in the RFC822-format
message body, and comparing it to patterns present in a table of
heuristics.
_C_o_n_c_l_u_s_i_o_n:
The intent of this paper is to document the current status and
future plans of those working on the mail user interface associ-
ated with the KA9Q Internet package. Because a great deal of
the detail about how the system is and will be put together is
still in a state of flux, it would seem inappropriate to discuss
that detail here. Those interested in following the progress
of, and/or assisting in the work remaining in this project, are
directed to contact one or both of the authors.
_R_e_f_e_r_e_n_c_e_s:
1. RFC821, Simple Mail Transfer Protocol.
2. RFC822, Standard for the Format of Internet Text Messages.
3. Allman, Eric, ``SENDMAIL - An Internetwork Mail Router'',
supplied with the 4bsd Unix manual set.
December 6, 1988
